Subject: DateAndTime versus TimeStamp for Counter Discontinuities

From: "R.E. (Robert) Moore (254-4436)" <[email-masked]>
Date: Wed, 21 Aug 96 09:16:29 EDT

Since we spent so much time on this last fall, I'd like us to have
a thorough discussion of it now.  Randy has said:

>|     Item:      29
>|     Page:      23
>|     Clause:    5
>|     Qualifier: major
>|     Rationale: RFC 1902 clause 7.1.6 requires that counters which can
>|                experience discontinuities at times other than manage-
>|                ment system re-initialization must identify an  object
>|                of  type  TimeStamp  which  can be monitored to detect
>|                such discontinuities.  This affects the definition  of
>|                appnPortDefLsGoodXids, appnPortDefLsBadXids, appnPort-
>|                DynLsGoodXids, and appnPortDynLsBadXids.
>|
>|     Proposal:  Add an appnPortStartedTimeStamp object to satisfy this
>|                requirement.
>|
>|BobM> This comment seems correct to me.  Do we want to add another
>|BobM> time stamp for these counters (presumably in our usual
>|BobM> DateAndTime format)?
>
>RFC 1902 clause 7.1.6 second paragraph requires a TimeStamp syntax.
>(One can argue whether that's really the best representation, but 1902
>is pretty explicit on this point.)

I think the following case can be made for our use of the DateAndTime
syntax for our discontinuity indicators:

1.  DateAndTime does a better job of indicating counter discontinuities
    than TimeStamp does.  If an agent follows the same script each time
    it comes up, then a link or port might come up at exactly the same
    time relative to when sysUpTime was started over and over.  (This is
    more likely if the agent, as some agents do, implements TimeTicks
    objects by counting whole seconds and multiplying by 100.)  Thus a
    TimeStamp might fail to signal a discontinuity, when a DateAndTime
    would.

2.  A Management Station will use a DateAndTime to identify a
    discontinuity in exactly the same way it uses a TimeStamp:  retrieve
    it with the counters, and see if it matches the value that was
    retrieved before.  If the two values match, subtract the counter
    values and treat the difference as significant.  If they don't match,
    take the counter discontinuity path.

3.  While it's unreasonable for RFC-1902 to require all SNMP agents to
    support DateAndTime, the agents *we* deal with are in, or closely
    associated with, APPN nodes, which must support date-and-time
    stamping anyway.  Thus it's reasonable for us to specify DateAndTime
    discontinuity indicators.

Summary:  DateAndTime provides a better indication of counter
discontinuities than TimeStamp does, our agents can provide it, and it
doesn't cause Management Stations any additional work.  Thus we should
be able to use it.  (I really don't think the authors of RFC-1902
intended to be placing an *upper* bound here on how well an agent could
identify counter discontinuities; my guess is that they just didn't
consider using DateAndTime for this purpose.)

If the rest of the WG / SIG agrees with this argument, maybe we can ask
Randy whether we should open a defect against RFC-1902, record a
deviation from RFC-1902, or do something else.

Bob Moore, IBM Network Management Architecture

---

From: "Bill Kwan" <[email-masked]>
Date: Mon, 30 Sep 1996 12:15:59 EST5EDT

Hi folks,

Hopefully, we have had enough time to review BobM's proposal on 
TimeStamps. Randy's position is that being a reviewer, he must 
cite RFC1902 on how it should be done (even if he might secretly
agree with Bob :-). He suggested that if the working group 
feels strongly enough about the issue that we should
get a ruling from Deirdre.

Does the working group feel strongly enough about this? 
Since we have had similar discussions on this subject before,
if I don't hear anyone strongly objecting within the next two weeks,
I will raise the issue to Deirdre.

Regards,
Bill

> Date:          Wed, 21 Aug 1996 10:03:03 -0400
> Reply-to:      [email-masked]
> From:          "R.E. (Robert) Moore (254-4436)" <[email-masked]>
> To:            [email-masked]
> Subject:       DateAndTime versus TimeStamp for Counter Discontinuities

---

From: "jim (j.) cobban" <[email-masked]>
Date: Mon, 7 Oct 1996 11:15:00 -0400

You will recall that I raised this issue quite some time ago.  My arguments
in favor of TimeStamp are:

  1) Everyone else does it with TimeStamp.  SNA is already looked upon as
     being a horrible disease which IP networks would rather not catch.  Why
     emphasize our wierdness by behaving in a different way in SNMP.
  2) SNA does not operate in isolation.  It uses interfaces whose MIBs use
     TimeStamp to report events.  Using two different time reporting methods
     increases the complexity of management systems which must correlate
     events on these interfaces to events happening in SNA.

To which the objection came from the support team for a certain product, which
I will refrain from identifying, that they had no mechanism for synchronizing
the clocks across their multiple processors, and therefore could NOT report a
TimeStamp.  That is we are permitting a design deficiency on a product which
has a negligeable share of the market to dictate the design of the MIBs.

Since I have nothing further to contribute, and since my employer really
doesn't care how this turns out, I will shut up now.